home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group Marvin Solomon
- Request for Comments: 930 Edward Wimmers
- Supersedes: RFC 884 University of Wisconsin - Madison
- January 1985
-
- TELNET TERMINAL TYPE OPTION
-
-
- Status of This Memo
-
- This RFC specifies a standard for the ARPA Internet community. Hosts
- on the ARPA Internet that exchange terminal type information within
- the Telnet protocol are expected to adopt and implement this
- standard. Distribution of this memo is unlimited.
-
- This standard supersedes RFC 884. The only change is to specify that
- the TERMINAL-TYPE IS sub-negotiation should be sent only in response
- to the TERMINAL-TYPE SEND sub-negotiation. See below for further
- explanation.
-
- 1. Command Name and Code
-
- TERMINAL-TYPE 24
-
- 2. Command Meanings
-
- IAC WILL TERMINAL-TYPE
-
- Sender is willing to send terminal type information in a
- subsequent sub-negotiation
-
- IAC WON'T TERMINAL-TYPE
-
- Sender refuses to send terminal type information
-
- IAC DO TERMINAL-TYPE
-
- Sender is willing to receive terminal type information in a
- subsequent sub-negotiation
-
- IAC DON'T TERMINAL-TYPE
-
- Sender refuses to accept terminal type information
-
- IAC SB TERMINAL-TYPE SEND IAC SE
-
- Sender requests receiver to transmit his (the receiver's) terminal
- type. The code for SEND is 1. (See below.)
-
-
-
-
-
- Solomon & Wimmers [Page 1]
-
-
- RFC 930 January 1985
- Telnet Terminal Type Option
-
-
- IAC SB TERMINAL-TYPE IS ... IAC SE
-
- Sender is stating the name of his terminal type. The code for IS
- is 0. (See below.)
-
- 3. Default
-
- WON'T TERMINAL-TYPE
-
- Terminal type information will not be exchanged.
-
- DON'T TERMINAL-TYPE
-
- Terminal type information will not be exchanged.
-
- 4. Motivation for the Option
-
- This option allows a telnet server to determine the type of terminal
- connected to a user telnet program. The transmission of such
- information does not immediately imply any change of processing.
- However, the information may be passed to a process, which may alter
- the data it sends to suit the particular characteristics of the
- terminal. For example, some operating systems have a terminal driver
- that accepts a code indicating the type of terminal being driven.
- Using the TERMINAL TYPE and BINARY options, a telnet server program
- on such a system could arrange to have terminals driven as if they
- were directly connected, including such special functions as cursor
- addressing, multiple colors, etc., not included in the Network
- Virtual Terminal specification. This option fits into the normal
- structure of TELNET options by deferring the actual transfer of
- status information to the SB command.
-
- 5. Description of the Option
-
- WILL and DO are used only to obtain and grant permission for future
- discussion. The actual exchange of status information occurs within
- option subcommands (IAC SB TERMINAL-TYPE...).
-
- Once the two hosts have exchanged a WILL and a DO, the sender of the
- DO TERMINAL-TYPE is free to request type information. Only the
- sender of the DO may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
- and only the sender of the WILL may transmit actual type information
- (within an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal
- type information may not be sent spontaneously, but only in response
- to a request.
-
- The terminal type information is an NVT ASCII string. Within this
-
-
- Solomon & Wimmers [Page 2]
-
-
- RFC 930 January 1985
- Telnet Terminal Type Option
-
-
- string, upper and lower case are considered equivalent. The complete
- list of valid terminal type names can be found in the latest
- "Assigned Numbers" RFC.
-
- The following is an example of use of the option:
-
- Host1: IAC DO TERMINAL-TYPE
-
- Host2: IAC WILL TERMINAL-TYPE
-
- (Host1 is now free to request status information at any time.)
-
- Host1: IAC SB TERMINAL-TYPE SEND IAC SE
-
- Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
-
- 6. Implementation Suggestions
-
- The "terminal type" information may be any NVT ASCII string
- meaningful to both ends of the negotiation. The list of terminal
- type names in "Assigned Numbers" is intended to minimize confusion
- caused by alternative "spellings" of the terminal type. For example,
- confusion would arise if one party were to call a terminal
- "IBM3278-2" while the other called it "IBM-3278/2". There is no
- negative acknowledgement for a terminal type that is not understood,
- but certain other options (such as switching to BINARY mode) may be
- refused if a valid terminal type name has not been specified. In
- some cases, a particular terminal may be known by more than one name,
- for example a specific type and a more generic type. In such cases,
- the sender of the TERMINAL-TYPE IS command should reply to successive
- TERMINAL-TYPE SEND commands with the various names, from most to
- least specific. In this way, a telnet server that does not
- understand the first response can prompt for alternatives. However,
- it should cease sending TERMINAL-TYPE SEND commands after receiving
- the same response two consecutive times. Similarly, a sender should
- indicate it has sent all available names by repeating the last one
- sent. Note that TERMINAL-TYPE IS must only be sent in response to a
- request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-TYPE
- IS and then received TERMINAL-TYPE SEND couldn't determine whether
- the other host was requesting a second option or the TERMINAL-TYPE
- SEND and the TERMINAL-TYPE IS crossed in midstream.
-
- The type "UNKNOWN" should be used if the type of the terminal is
- unknown or unlikely to be recognized by the other party.
-
-
-
-
-
- Solomon & Wimmers [Page 3]
-
-
- RFC 930 January 1985
- Telnet Terminal Type Option
-
-
- The complete and up-to-date list of terminal type names will be
- maintained in the "Assigned Numbers". The maximum length of a
- terminal type name is 40 characters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Solomon & Wimmers [Page 4]